-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow Pipelines to be used with different Resources #248
Allow Pipelines to be used with different Resources #248
Conversation
rr, err := c.resourceLister.PipelineResources(ns).Get(source.ResourceRef.Name) | ||
for _, r := range inputs { | ||
inputMapping[r.Name] = "" | ||
// TODO(#213): if this is the empty string should it be an error? or maybe let the lookup fail? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: i plan to follow up on #213 next!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
amazing changes, the yaml files are so much better now, but only one concern with the version information missing for the resources
// GetVersion returns the revision of the resource, See | ||
// https://git-scm.com/docs/gitrevisions#_specifying_revisions for | ||
// more details what the revison in github is | ||
func (s GitResource) GetVersion() string { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we still need a version for the git resource so it knows what to clone, or is this information somewhere else now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well the git resource fortunately still has the "revision" field, so as long as we are okay with having logic specific to Git (which I think we'd need anyway) I think we are still good
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -61,11 +61,6 @@ func (s ImageResource) GetType() PipelineResourceType { | |||
return PipelineResourceTypeImage | |||
} | |||
|
|||
// GetVersion returns the version of the resource | |||
func (s ImageResource) GetVersion() string { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same for image, we still need to know which digest to pull, or where is that information coming from? I can't find it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
image has a digest
field:
It does mean the logic to interact with these types needs to know what type it's dealing with
(I'm thinking that we could have something kind of cool if in #238 we go the route of using Resources as an extension point, and use duck-typing for resources, then a Resource's controller can take care of itself, so it can know about the Resource's functionality specific attributes like an image's digest or a git resource's commitish)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm... that sounds interesting
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to also know the type to handle passing these resources for further tasks. It is tough to come up universal solution for all resource types.
@@ -71,9 +71,6 @@ func AddInputResource( | |||
if err != nil { | |||
return nil, fmt.Errorf("task %q invalid Pipeline Resource: %q", task.Name, boundResource.ResourceRef.Name) | |||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need to provide to the git clone command the revision or it will always get master I believe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think it's okay b/c the revision
field is used
I'll make sure tho that the tests have a least one case with a custom revision!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like there isn't one yet, i'll add it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, that works.
0c9529d
to
1963376
Compare
@pivotal-nader-ziada I re-added the test case that I (shouldn't have) removed for the branch case, now updated to get the branch from the resource instead, PTAL |
I should make sure this is clear in the docs too! |
Okay added some more docs :D |
d03458b
to
8ebf1f5
Compare
whoops! should have ran the tests after rebasing :D |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🦁
Just need a small rebase 😝
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bobcatfish, vdemeester The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This change makes it possible to reuse a Pipeline with different Resources without having to change the Pipeline itself. It does this by moving the linking of the Resources a Task requires from the Pipeline into the PipelineRun. The relationship between Resources and the Tasks that are expected to be executed on them is still expressed in the Pipeline (via `providedBy`). ResourceBindings move from Pipeline to PipelineRun and become ResourceDependencies. No longer calling these "bindings" in the API or using the term "source" fixes + the additional docs in using.md fixes tektoncd#139. The most difficult part of this change was updating validatePipelineTaskAndTask - hoping to refactor this in a follow up (which would also address tektoncd#213). This interface is still probably not in its final form and hopefully we can iterate on it! Fixes tektoncd#200
We had been hoping to use `version` to cover two cases: 1. To allow a user to override the version of the Resource they are using (e.g. for a particular git resource, use a different revision) 2. For the case where a Task modifies a resource then provides it to the next Task, we wanted to express the modification in the version In the previous commit, we made it so that a user can change a Resource by creating a new one and specifying the new one in teh PipelineRun, and they can do the same thing via a TaskRun. For the second case, in #124 @shashwathi is designing how the output of one task will be passed to the next, and it is likely going to be via PVCs and will not need the version field. Fixes tektoncd#200
After removing `version` field, trying to make sure it is clear how to use specific commits/digests/branches/forks without the `version` field. Also fixed `/workspace` docs which hadn't been updated to include multiple input changes #123
8ebf1f5
to
7e2c673
Compare
The following is the coverage report on pkg/.
|
/lgtm /meow space |
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Readd nop and move knative-images to tekton-images
This will emove the binding field we have deprecated in 0.2 in favours of bindings Fix tektoncd#248
This change makes it possible to reuse a Pipeline with different Resources without having to change the Pipeline itself. It does this by moving the linking of the Resources a Task requires from the Pipeline into the PipelineRun.
The relationship between Resources and the Tasks that are expected to be executed on them is still expressed in the Pipeline (via
providedBy
).ResourceBindings move from Pipeline to PipelineRun and become ResourceDependencies. No longer calling these "bindings" in the API or using the term "source" fixes + the additional docs in using.md fixes #139.
Removing version b/c we had been hoping to use
version
to cover two cases:But now a user can "change" a Resource by creating a new one and specifying the new one in teh PipelineRun, and they can do the same thing via a TaskRun.
For the second case, in #124 @shashwathi is designing how the output of one task will be passed to the next, and it is likely going to be via PVCs and will not need the version field.
This interface is still probably not in its final form and hopefully we can iterate on it!
Fixes #200